Method for reporting latency of packet transmission in communication network

ABSTRACT

Method for reporting latency of packet transmission in a communication network. The method includes receiving by an entity an UL packet from a UE at a first time unit, wherein the UL packet includes a second time unit at which the packet is sent from the UE. Measuring by the entity a latency in transmission of the packet based on a time difference between the first time unit and the second time unit and performing by the entity at least one action based on the latency. Receiving by a UE a DL packet from an entity at a first time unit, wherein the DL packet comprises a second time unit at which the packet is transmitted from the entity. Measuring by the UE a time difference between the first time unit and the second time unit for the DL packet. Reporting by the UE a latency report to the entity.

TECHNICAL FIELD

The present invention relates to wireless communication network and moreparticularly relates to a mechanism for reporting latency of a packettransmission in a communication network.

BACKGROUND ART

Minimization of Drive Test (MDT) is introduced in third generationpartnership project (3GPP) to reduce the rigorous drive tests done byoperators to collect network (NW) performance metrics in their networkfor the NW optimization. The MDT significantly reduces the NWmaintenance costs for the operators, ensures faster optimization cycleresulting in higher customer satisfaction and nonetheless help to reducethe carbon emission to protect the environment. Furthermore, it enablesoperators to collect measurements from areas which are not accessiblefor drive tests (e.g. narrow roads, forests, private land/house/office).

The MDT is a mechanism to provide feedback to an eNodeB (eNB) about thenetwork performance and its impact on User Equipment(s) (UEs) served bythe corresponding network. As provisioned in the current specification3GPP TS 36.331, the MDT supports reporting of radio link relatedstatistics to the NW. Based on these reports the eNB or the NW mayperform some corrective actions in order to minimize the failure fromrecurring frequently and thereby improving the service quality. The 3GPPRelease 11 MDT is aimed at defining methods in context of quality ofservice (QoS) verification. Measuring end user QoS focused onmeasurement of bit rate for non-guaranteed bit rate (NGBR) type datastatistics only.

However these mechanisms are beneficial only to the non-guaranteed bitrate kind of traffic and do not suit GBR traffic in a similar way (e.g.Multimedia Telephony (MMTEL) Voice/video services). Most operators usethe GBR type traffic to provide the MMTEL voice/video services.Therefore the MDT mechanisms have to be enhanced to provide efficientsupport of MMTEL voice/video type traffic statistics. 3GPP hasintroduced new study item. Further the MDT enhancements in the 3GPPrelease 13 with a focus of providing solution for enhanced QoSverification which cover latency and packet drop or loss metrics andenhanced coverage optimization for MMTEL services which covers theimpact on MDT measurements due to Inter-Cell Interference Coordination(ICIC) and Enhanced Inter-Cell Interference Coordination (eICIC).

The GBR traffic like MMTEL voice/video is real time in nature and iserror tolerant but are non-delay tolerant services. In addition tojitters, the quality of the voice/video service depends largely on theend to end latency in communication. The 3GPP recommended latency valuesfor voice/video real time services are shown in Table 1 below:

TABLE 1 Key performance parameters and target values Delay End-to-endOne- Variation Degree of way within a Information Medium Applicationsymmetry Data rate Delay call loss Audio Conversational Two-way  4-25kb/s <150 msec <1 msec <3% FER voice preferred <400 msec limit Note 1Video Videophone Two-way 32-384 kb/s <150 msec <1% FER perferred <400msec limit Lip-synch: <100 msec

Therefore, mechanisms to improve quality of the GBR services have to beintroduced. The GBR services are generally real time in nature and areerror tolerant but non-delay tolerant services. Therefore, the qualityof these real time services depends on how the delay and errors aregetting affected.

Latency is one of the important metric for QoS verification especiallyfor GBR services or MMTEL services which are real time and impact theend user experience. This metric can really help in improving the NWperformance by improving the NW capacity. The various reasons forLatency can be as below:

Insufficient UL grants from the network for transmitting the generatedvoice/video packet

Weak UL channel from the transmitting UE to the network leading topacket drops over the air interface and increasing number ofretransmissions

Layer 3 Communication latency in carrying the traffic from the eNBconnected to the transmitting UE to the eNB connected to the receivingUE

Weak DL channel from the receiving eNB to the UE attempting to receivethese packets in DL.

eNB not scheduling the receiving UE fast enough due to non-availabilityof resource/congestion/poor scheduling decisions.

DISCLOSURE OF INVENTION Technical Problem

Poor scheduling decisions or delay in allocation of resources forcarrying voice/video traffic or other GBR traffic occur at differentstages since the network is unaware of the latency/communication delayincurred during the process. According to 3GPP TS36.314, the packetdelay in DL [′Packet Delay in the DL per QCI″] is measured by the eNB asthe time difference between “the point in time when the last piece ofPacket Data Convergence Protocol (PDCP) service data unit (SDU) wasreceived by the UE according to received HARQ feedback information” and“the point in time when PDCP SDU arrives at the PDCP entity”. The delaytime measured by the eNB is not accurate in that:

The point in time when the UE receives a HARQ data and when the eNBreceives the HARQ feedback are different, and;

HARQ reordering time, radio link control (RLC) processing time, and thePDCP processing time are not considered.

Therefore, the existing “DL (DL) packet delay measurement” is notsuitable for measuring delay. Also, an UL (UL) delay/latency measurementis not defined in the TS36.314.

Solution to Problem

The principal object of the embodiments herein is to provide a methodfor reporting latency of a packet transmission in a communicationnetwork.

Another object of the embodiments herein is to provide a method forreceiving by an entity an UL packet from the UE at a first time unit,wherein the UL packet includes a second time unit at which the packet issent from the UE.

Another object of the embodiments herein is to provide a method formeasuring by the entity, latency in transmission of the packet based ona time difference between the first time unit and the second time unit.

Another object of the embodiments herein is to provide a method forperforming by the entity at least one action based on the latency.

Another object of the embodiments herein is to provide a method forreceiving by a UE, a DL packet from an entity at a first time unit,wherein the DL packet comprises a second time unit at which the packetis transmitted from the entity.

Another object of the embodiments herein is to provide a method formeasuring by the UE a time difference between the first time unit andthe second time unit for the DLpacket.

Another object of the embodiments herein is to provide a method forreporting by the UE a latency report to the entity, wherein the latencyreport includes the time difference for transmission of the DL packet tothe entity.

Another object of the embodiments herein is to provide a method forreporting a packet discard in a communication network includes loggingby the UE a number of packets discarded and reporting by the UE a packetdiscard report including the number of packets discarded to the entity.

Another object of the embodiments herein is to provide a method forreporting a packet discard in a communication network includes receivingby the apparatus a packet discard report from the UE and performing atleast one action based on the time difference.

Yet another object of the embodiments herein is to provide a method formeasuring and calculating delay in both the DL and the UL directions forMMTELservices.

Yet another object of the embodiments herein is to provide a mechanismfor determining UL latency by time stamping DL PDCP protocol data unit(PDU).

Yet another object of the embodiments herein is to provide a mechanismfor determining DL latency by time stamping DL PDCP PDU.

Yet another object of the embodiments herein is to provide a mechanismfor determining and reporting UL packet discard.

BRIEF DESCRIPTION OF DRAWINGS

This invention is illustrated in the accompanying drawings, throughoutwhich like reference letters indicate corresponding parts in the variousfigures. The embodiments herein will be better understood from thefollowing description with reference to the drawings, in which:

FIG. 1 illustrates block diagram of an apparatus, according to anembodiment as disclosed herein;

FIG. 2 illustrates block diagram of a UE, according to an embodiment asdisclosed herein;

FIG. 3 is a flow diagram illustrating a method for reporting latency ina UL transmission, according to an embodiment as disclosed herein;

FIG. 4 is a flow diagram illustrating a method for reporting latency ina DL transmission to the apparatus, according to an embodiment asdisclosed herein;

FIG. 5 is a sequence diagram illustrating various signaling messagesinvolved in the DL latency determination, according to an embodiment asdisclosed herein;

FIG. 6 is a sequence diagram illustrating steps for determining the DLby means of the DL PDU time stamping, according to embodiments asdisclosed herein;

FIGS. 7a-7c illustrate a sequence diagram illustrating various RRCmessages for reporting the DL latency report to the apparatus, accordingto an embodiment as disclosed herein;

FIG. 8 is a sequence diagram illustrating various signaling messagesinvolved in the UL latency determination by time stamping, according toembodiments as disclosed herein;

FIG. 9 is a sequence diagram illustrating steps for determining the ULlatency by means of the UL PDU time stamping, according to embodimentsas disclosed herein;

FIGS. 10a-10b illustrate different PDU formats using which the PDCP dataPDU are time stamped, according to embodiments as disclosed herein;

FIGS. 11a-11b illustrate different PDU formats using which the PDCPstatus PDU are time stamped with reference time value, according toembodiments as disclosed herein;

FIG. 12 illustrates the new PDCP control PDU introduced for indicatingthe time stamp to the UE, according to an embodiment as disclosedherein;

FIG. 13 is a sequence diagram illustrating various steps involved inreporting discarded packets to the apparatus, according to embodimentsas disclosed herein;

FIGS. 14a and 14b illustrate a PDCP UL discarded packet report controlPDU, according to embodiments as disclosed herein;

FIGS. 15a-15c are sequence diagrams illustrating UL discard packetstatistics are reported as a part of an RRC message, according toembodiments as disclosed herein; and

FIG. 16 illustrates a computing environment implementing the method forreporting latency of the packet transmission in the communicationnetwork, according to an embodiment as disclosed herein.

MODE FOR THE INVENTION

The embodiments herein and the various features and advantageous detailsthereof are explained more fully with reference to the non-limitingembodiments that are illustrated in the accompanying drawings anddetailed in the following description. Descriptions of well-knowncomponents and processing techniques are omitted so as to notunnecessarily obscure the embodiments herein. Also, the variousembodiments described herein are not necessarily mutually exclusive, assome embodiments can be combined with one or more other embodiments toform new embodiments. The term “or” as used herein, refers to anon-exclusive or, unless otherwise indicated. The examples used hereinare intended merely to facilitate an understanding of ways in which theembodiments herein can be practiced and to further enable those skilledin the art to practice the embodiments herein. Accordingly, the examplesshould not be construed as limiting the scope of the embodiments herein.

As is traditional in the field, embodiments may be described andillustrated in terms of blocks which carry out a described function orfunctions. These blocks, which may be referred to herein as units ormodules or the like, are physically implemented by analog and/or digitalcircuits such as logic gates, integrated circuits, microprocessors,microcontrollers, memory circuits, passive electronic components, activeelectronic components, optical components, hardwired circuits and thelike, and may optionally be driven by firmware and/or software. Thecircuits may, for example, be embodied in one or more semiconductorchips, or on substrate supports such as printed circuit boards and thelike. The circuits constituting a block may be implemented by dedicatedhardware, or by a processor (e.g., one or more programmedmicroprocessors and associated circuitry), or by a combination ofdedicated hardware to perform some functions of the block and aprocessor to perform other functions of the block. Each block of theembodiments may be physically separated into two or more interacting anddiscrete blocks without departing from the scope of the disclosure.Likewise, the blocks of the embodiments may be physically combined intomore complex blocks without departing from the scope of the disclosure.

Accordingly the embodiments herein provide an apparatus for reportinglatency of a packet transmission in a communication network. Theapparatus includes a memory, a processor, coupled to the memory. Theprocessor configured to receive an UL packet from a UE at a first timeunit, wherein the UL packet comprises a second time unit at which thepacket is sent from the UE. Further, the processor is configured tomeasure latency in transmission of the packet based on a time differencebetween the first time unit and the second time unit. Further, theprocessor is configured to perform at least one action based on thelatency.

Accordingly the embodiments herein provide a UE for reporting latency ofa packet transmission in a communication network. The UE includes amemory, a processor coupled to the memory. The processor configured toreceive a DL packet from an entity at a first time unit, wherein the DLpacket comprises a second time unit at which the packet is transmittedfrom the entity. Further, the processor is configured to measure a timedifference between the first time unit and the second time unit for theDL packet. Further, the processor configured report a latency report tothe entity. The latency report includes the time difference fortransmission of the DL packet.

Accordingly the embodiments herein provide a UE for reporting latency ofa packet transmission in a communication network. The UE includes amemory, a processor and an entity, coupled to the processor. The entitycoupled to the processor configured to receive an UL packet from the UEat a first time unit, wherein the UL packet comprises a second time unitat which the packet is sent from the UE. Further, the processorconfigured to measure latency in transmission of the packet based on atime difference between the first time unit and the second time unit.Further, the processor configured to perform at least one action basedon the latency.

Unlike conventional system, the proposed system and method can beachieved by reporting latency (For example: delay) of a packettransmission in a communication network (For example: UL (UL) and DL(DL)) or by facilitating the apparatus (for example: eNB) for measuringthe delay (in UL). This will provide the eNB with knowledge about theaccurate delay/latency measurements. With the accurate latencymeasurements, the network may be able to determine the time it takes forDL and UL communication so that the apparatus may take the necessaryactions to prevent excessive delay in communication. The method canreport the MMTEL call statistics to the network via a MDT to improve theservice quality.

Referring now to the drawings, and more particularly to FIGS. 1 through16, where similar reference characters denote corresponding featuresconsistently throughout the figures, these are shown in preferredembodiments.

FIG. 1 illustrates block diagram of an apparatus 100, according to anembodiment as disclosed herein.

In an embodiment, the apparatus 100 includes a reporting module 102, anupper layer entity 104, a transmission entity 106, a receiver entity108, lower layer entity 110, a processor 112 coupled to a memory 114 anda communicator 116. The apparatus 100 can include, for example, an eNB,evolved universal terrestrial access network (E-UTRAN), a pico cell, amacro cell, a network entity, an entity, or the like. The processor 112may be for example; a hardware unit, a Central Processing Unit (CPU), aGraphics Processing Unit (GPU)) communicatively coupled to a memory 114(e.g., a volatile memory and/or a non-volatile memory); the memory 114includes storage locations configured to be addressable through theprocessor 112.

In an embodiment, the processor 112 can be configured to receive the ULpacket from the UE at the first time unit. The first time unitcorresponds to the time at which processing of the received packet iscompleted at the processor 112. The UL packet includes, for example, asecond time unit at which the packet is sent from the UE. The secondtime unit corresponds to a time at which the packet is received by theprocessor 112. The reporting module 102 can be configured to measure thelatency in transmission of the packet based on the time differencebetween the first time unit and the second time unit. Further, thereporting module 102 can be configured to perform one or more actionsbased on the latency.

For example, the one or more actions may include initiating/triggeringpreventive measures based on the measured latency. The preventivemeasures are conventionally known in the art.

The memory 114 may store the first time unit, the second time unit andthe difference between the first time unit and the second time unit. Thememory may also store the latency report which includes the differencebetween the first time unit and the second time unit. The memory unit114 may include one or more computer-readable storage media. The memory114 may include non-volatile storage elements. Examples of suchnon-volatile storage elements may include magnetic hard discs, opticaldiscs, floppy discs, flash memories, or forms of electricallyprogrammable memories (EPROM) or electrically erasable and programmable(EEPROM) memories. In addition, the memory 114 may, in some examples, beconsidered a non-transitory storage medium. The term “non-transitory”may indicate that the storage medium is not embodied in a carrier waveor a propagated signal. However, the term “non-transitory” should not beinterpreted to mean that the memory 114 is non-movable. In someexamples, the memory 114 can be configured to store larger amounts ofinformation than the memory. In certain examples, a non-transitorystorage medium may store data that can, over time, change (e.g., inRandom Access Memory (RAM) or cache).

FIG. 2 illustrates block diagram of a UE 200, according to an embodimentas disclosed herein.

The UE 200 includes a reporting module 202, an upper layer entity 204, atransmit entity 206 (i.e., Tx entity), a receiver entity 208 (i.e., Rxentity), a lower layer entity 210, a processor 212 coupled to a memory214 and a communicator 216. The UE 200 can include a mobile phone, asmart phone, Personal Digital Assistants (PDAs), a tablet, a phablet, aconsumer electronic device, dual display devices, edge display device,electronic device, machine to machine device, or the like. The processor212 may be for example; a hardware unit, a Central Processing Unit(CPU), a Graphics Processing Unit (GPU)) communicatively coupled to amemory 214 (e.g., a volatile memory and/or a non-volatile memory); thememory 214 includes storage locations configured to be addressablethrough the processor 212.

In an embodiment, the processor 212 can be configured to receive the DLpacket from the apparatus 100 at the first time unit. The first timeunit corresponds to the time at which processing of the received DLpacket is completed at the UE 200. The DL packet includes the secondtime unit at which the packet is transmitted from the apparatus 100. Thesecond time unit corresponds to the time at which the DL packet isarrived at the upper layer entity 204 of the apparatus 100 (for example,the entity). The reporting module 202 can be configured to measure atime difference between the first time unit and the second time unit forthe DL packet. Further, the reporting module 202 can be configured toreport the latency report to the apparatus 100. The latency reportincludes the time difference for transmission of the DL packet.

The memory 214 may store the first time unit, the second time unit andthe difference between the first time unit and the second time unit. Thememory may also store the latency report which includes the differencebetween the first time unit and the second time unit. The memory 214 mayinclude one or more computer-readable storage media. The memory 214 mayinclude non-volatile storage elements. Examples of such non-volatilestorage elements may include magnetic hard discs, optical discs, floppydiscs, flash memories, or forms of electrically programmable memories(EPROM) or electrically erasable and programmable (EEPROM) memories. Inaddition, the memory 214 may, in some examples, be considered anon-transitory storage medium. The term “non-transitory” may indicatethat the storage medium is not embodied in a carrier wave or apropagated signal. However, the term “non-transitory” should not beinterpreted to mean that the memory 214 is non-movable. In someexamples, the memory 214 can be configured to store larger amounts ofinformation than the memory. In certain examples, a non-transitorystorage medium may store data that can, over time, change (e.g., inRandom Access Memory (RAM) or cache).

FIG. 3 is a flow diagram illustrating a method for reporting latency ina UL transmission, according to an embodiment as disclosed herein.

At step 302, the method includes receiving the UL packet from the UE 200at the first time unit at which the packet is sent from the UE 200. Inan embodiment, the method allows the reporting module 102 to receive theUL packet from the UE 200 at the first time unit at which the packet issent from the UE 200. The UL packet also includes the second time unit,wherein the second time unit corresponds to the time at which processingof the received packet is completed and the packet is transmitted to alower layer entity 110.

At step 304, the method includes measuring latency in transmission ofthe packet based on the time difference between the first time unit andthe second time unit. In an embodiment, the method allows the reportingmodule 102 to measure the latency in transmission of the packet based onthe time difference between the first time unit and the second timeunit.

At step 306, the method includes performing at least one action based onthe latency. In an embodiment, the method allows the reporting module102 to perform at least one action based on the latency.

The various actions, acts, blocks, steps, or the like in the method ofthe flow diagram 300 may be performed in the order presented, in adifferent order or simultaneously. Further, in some embodiments, some ofthe actions, acts, blocks, steps, or the like may be omitted, added,modified, skipped, or the like without departing from the scope of theinvention.

FIG. 4 is a flow diagram 400 illustrating a method for reporting latencyin the DL transmission to the apparatus 100, according to an embodimentas disclosed herein.

At step 402, the method includes receiving the DL packet from theapparatus 100 at the first time unit. In an embodiment, the methodallows the reporting module 202 to receive the DL packet from theapparatus 100 at the first time unit. The DL packet includes the secondtime unit at which the packet is transmitted from the apparatus 100.

At step 404, the method includes measuring the time difference betweenthe first time unit and the second time unit for the DL packet. In anembodiment, the method allows the reporting module 202 to measure thetime difference between the first time unit and the second time unit forthe DL packet.

At step 406, the method includes reporting the latency report to theapparatus 100. In an embodiment, the method allows the reporting module202 to report the latency report to the apparatus 100. The latencyreport includes the time difference for transmission of the DL packet.

In an embodiment, the method determines the DL latency by time stampingDL PDCP PDU. For example, in the DL the Tx entity 106 (i.e., PDCP) ofthe apparatus 100 receives packets from other network nodes or the S-GW(Serving Gateway). The start of a LTE packet air interface life cycle inthe DL direction begins on its arrival at the PDCP for transmissionrelated processing. Once the PDU is successfully transmitted in the DLto the UE 200 and the receiver entity 208 (i.e., PDCP) at the UE 200 isready to provide the received PDU to the upper layer entity 204, acommunication delay in the DL is calculated. The packet delay in the DLis measured by computing the time difference between the first time unitand the second time unit (i.e., “point in time PDCP SDU is provided tothe upper layer entity 204 by the PDCP receiver entity 208 and “point intime when the PDCP SDU arrives at the PDCP Tx entity 106”). This latencymeasurement takes into account the HARQ retransmissions, reorderingdelay, the RLC retransmissions/RLC processing time and PDCP processingtime as well. The measured delay/latency is then reported to theapparatus 100 for taking corrective actions.

The various actions, acts, blocks, steps, or the like in the method ofthe flow diagram 400 may be performed in the order presented, in adifferent order or simultaneously. Further, in some embodiments, some ofthe actions, acts, blocks, steps, or the like may be omitted, added,modified, skipped, or the like without departing from the scope of theinvention.

FIG. 5 is a sequence diagram illustrating various signaling messagesinvolved in the DL latency determination, according to an embodiment asdisclosed herein. The Tx entity 106 (i.e, PDCP) of the apparatus 100receives packets from other network nodes like S-GW. On arrival of PDCPSDU at the transmit entity 106, a reference time value is added to thepacket/SDU/PDU. The PDCP SDU/PDU is time stamped (502) with the value ofSFN and sf number at which the packet arrived from upper layer entity104. For example, if the apparatus 100 detects that if the triggers forthe time stamping are satisfied, then the apparatus 100 may time stampedPDCP packet(s) with the SFN and sf number, where the packets are arrivedfrom other network nodes (i.e., SGW). Therefore it is not alwaysdesirable to time stamp each of the PDCP DL PDU. The time stampingdecision for a PDCU may depend on several factors and the triggersleading to decide time stamping of the PDU as are provided below:

Every DL packet

First DL packet on the bearer/QCI

For the zeroth DL PDCP SN

Periodic time stamping of SDU/PDU based on a defined periodicity

When first DL PDCP SDU is discarded from transmission

When DL PDCP SDU discard at NW (i.e., apparatus 100) PDCP Tx entity 106increases over a threshold

When the HARQ ACK is not received after a defined number ofattempts/retransmissions.

When a status PDU is received from the UE 200.

Once the packet is transmitted (504) to the UE 200, the UE 200 PDCPreceive entity 208 receives (506) the packet successfully thereof isprovided to upper layer entity 204. Before providing the packet to upperlayer 204, the SFN and sf number at which the packet has completed thePDCP receive processing is estimated. The latency in the DLcommunication is calculated (506) as the time different between the“SFN, sf” at which the receive PDCP processing is completed and the“SFN, sf” present in the received PDU. The DL latency can be calculatedby the UE 200 (based on time of reception of time stamped packet) or bythe apparatus 100 based on the received SFN, sf information andgenerates a latency report. Further, the UE 200 trigger for sending(508) the latency report is satisfied, then the UE transmits (510) timeDL latency report to apparatus 100. For example, in the DL latencycalculation is the actual method of determining the DL latency isdetailed in conjunction with FIG. 6. The reporting of the calculated DLlatency to the apparatus 100 is detailed in conjunction with FIGS. 7a-7c. The apparatus 100 on receiving (512) the latency report will evaluatethe latency report and performs corrective actions.

The FIG. 6 is a sequence diagram illustrating steps for determining theDL by means of the DL PDU time stamping, according to embodiments asdisclosed herein.

T1 is the timeframe at which the PDCP data arrival for the DLtransmission from other apparatus/network nodes/the upper layer entity104 to the time taken for forming PDCP PDU and transmitting it to thelower layer entity 110 (i.e., lower PDCP SAP/RLC). During the time frameof the T1, along with the regular PDCP transmission PDU processing, thePDCP transmit entity 106 time stamps (602) the DL PDU with the referencetime value (e.g. SFN and sf number at which the packet arrived fromupper layer entity 104) and then the time stamped PDU is provided to thelower layer entity 110. Further, the RLC, the MAC and the PHY processingis performed (604) following which the time stamped PDU is transmittedover the air interface to the UE 200 during a time frame T2. The timeframe T2 also includes the MAC PDU formation, the HARQ procedures, andother PHY processing is involved in preparing the DL transport block fortransmission. T3 is the time frame where the UE 200 receives thetransmitted packet and completes the PHY, the MAC and the RLC processing(606) and provides the PDU packet to upper layer entity/PDCP 204.Further, T3 includes the HARQ reordering procedure, HARQretransmissions, the PHY layer processing, MAC de-multiplexing, RLC SDUformation, RLC reordering and other related L2 procedures. T4 is time atwhich the reception of the packet at the UE 200 PDCP/PDCP lower SAP/RLCupper SAP to the time at which the packet is provided to the upper PDCPupper SAP/upper layer entity 204 for post PDCP processing (608). DuringT4, the PDCP Rx entity 208 decodes (610) the time stamped value andcalculates the DL latency for the received packet (e.g. SFN, sf at whichthe Rx entity 208 has completed processing the PDU and the time stampvalue added to the PDU). This measured latency is the DL packettransmission latency and will include the delays introduced during T1,T2, T3 and T4 (time taken from the point in time the data arrived at thePDCP Tx entity 106 to the point in time at which the packet is providedto upper layer entity 204 by the PDCP Rx entity 208).

Unlike conventional systems and methods, improvements in service qualitycan be achieved only if the apparatus 100 is aware of the calculateddelay metric/statistics. Therefore, the calculated latency report (forexample: DL/UL packet reception latency) is reported to the apparatus100. The latency report including the calculated DL or UL latency istransmitted by the UE 200 to the apparatus 100 in one of the followingways:

The first UL PDCP data PDU following the reception of the time stampedDL PDU.

New PDCP control PDU transmitted in the UL immediately after receptionof the DL time stamped PDU.

On receiving a request/command from the apparatus 100 for sending thelatency report (e.g., via RRC connection reconfiguration, UE assistanceinformation or the like).

On performing re-establishment (optionally configured by the apparatus100).

As a part of first status PDU following reception of the time stampedPDU.

Periodically based on the periodicity configured by the apparatus 100.The value reported may either be the latency calculated from the lastreceived time stamped PDU or an average of latencies calculated from thelast transmission of last latency report (if any) to the presenttrigger. Further, when the latency for one or more DL packet(s) exceed aconfigured threshold latency value.

In an embodiment, for example, the latency can be calculated by theapparatus 100. On satisfying the criteria for reporting the DL latencyto the apparatus 100, the UE 200 may report to the apparatus 100 thetime stamp at which the PDCP PDU has successfully completed the PDCPreceive processing and is ready to be provided to the upper layer(s)entity 204. Further, the apparatus 100 is either aware of the time atwhich the packet arrived at its PDCP Tx entity 106 from the SGW.Further, by determining the time difference between the apparatus 100stored values (i.e., the first time unit) and the time stamp (i.e., thesecond time unit) provided in the report received from the UE 100, theapparatus can calculate the DL latency.

In an embodiment, for example, the latency can be calculated by the UE200. On receiving a time stamped DL PDU from the apparatus 100, the UE200 calculates the DL latency by measuring the time difference betweenthe time stamp (second time unit) present in the DL PDU and the time atwhich UE 200 Rx entity 208 has completed its processing. Further, the UE200 reports the measured DL communication latency on that bearer/QCI tothe network.

Format of the PDCP DL latency report: The DL latency report may be senteither as a part of the PDCP PDU itself or as a part of the RRC message.In the former case, it can either be sent as a new or a part of anexisting UL control PDU or as a part of the UL data PDU as illustratedin FIGS. 10a and 10b , FIGS. 11a and 11b and the FIG. 12. The report mayeither contain the SFN or the sf values at which the time stamped DLPDUs were received (When DL latency is calculated by the apparatus 100)or the calculated latency values in unit of milliseconds (when DLlatency calculated by the UE 200).

The actual latency is not reported in all the cases where the SFN andthe sf numbers are reported to the apparatus 100. The time stamp ofreception is reported to the apparatus 100 to calculate the latency.Alternatively, the UE 200 may calculate the DL latency using the timestamp available in the received PDU and report the calculated latency tothe apparatus 100. Under such cases, the DL latency report within thePDCP UL PDU will contain the actual latency (Delay field) instead of thereception time stamp. In order to achieve a delay calculation precisionof 1 ms, the UE 200 will determine and report the number of sub-framesbetween the point of time at which time stamp is added to the PDU andthe point of time at which the Rx entity 108 has completed processingthe PDU and ready to provide the packet to the upper layer (s) entity104. For a precision of up to 10 ms, the UE 200 can measure and reportthe latency in unit of the SFN numbers.

The DL packet latency can also be reported as a part of the RRC messagein one of the following ways:

If DL latency report is requested through the RRC connectionreconfiguration message, the latency report is sent to the apparatus 100through the associated RRC connection reconfiguration complete messageas illustrated in conjunction with FIG. 7 a.

As a part of the UE 200 assistance information as illustrated inconjunction with the FIG. 7 c.

If configured by the apparatus 100 to provide the latency reports as apart of RLF recovery mechanisms/re-establishment procedure, the latencyreport is sent to the apparatus 100 during the RRC connectionre-establishment request or complete message.

If the re-establishment to the network/apparatus 100 failed, then thelatency report is optionally shared to the apparatus 100 over the nextRRC connection setup complete message (if configured by the apparatus100.

If the DL latency report is requested through the UE 200 informationrequest message, then the report is sent to the apparatus 100 as part ofthe UE 200 n information response as illustrated in conjunction withFIG. 7 b.

The FIGS. 7a-7c illustrates a sequence diagram illustrating various RRCmessages for reporting the DL latency report to the apparatus 100,according to an embodiment as disclosed herein.

As illustrated in the FIG. 7a , the RRC connection reconfigurationmessage from the apparatus 100 requests (702 a) the UE 200 to log and(or) send the measured DL or the UL latency to the apparatus 100. The UEthen sends (704 a) the measured DL or the UL latency or the receivedtime stamp to the apparatus over the RRC connection reconfigurationcomplete message.

As illustrated in the FIG. 7b , the RRC connection reconfigurationmessage from the apparatus 100 requests (702 b) the UE 200 to log and(or) send the measured DL or UL latency to the apparatus 100. The UE 200after completing the RRC connection reconfiguration proceduresuccessfully transmits (704 b) the UE 200 assistance information to theapparatus 200 containing the measured DL or the UL latency or thereceived time stamp.

As illustrated in the FIG. 7c , the UE 200 information request messagefrom the apparatus 100 requests (702 c) the UE 200 to log and (or) sendthe measured DL or UL latency to the apparatus 100. The UE 200 thensends (704 c) the measured DL/UL latency, or the received time stamp tothe apparatus 100 over the information response message from the UE 200.The DL or UL latency report may contain, for example, informationelements (IEs) which indicate the latency in the DL or the UL fordifferent radio bearers or for a single radio bearer as requested by thenetwork/apparatus 100. If the apparatus 100 requests latency report fora specific bearer, the UE 200 reports the value only for the requestedradio bearer. Otherwise, the UE 200 reports the latency for all theactivated bearers in order of activation of the same.

log LatencyReportReq-r13

rb-Identity [Optional]

log LatencyAvailable-r13 [TRUE]

dlLatencyRBid AbsoluteTimeInfo-r13

AbsoluteTimeInfo-r13 bit string (max DL delay)

FIG. 8 is a sequence diagram illustrating various signaling messagesinvolved in the UL latency determination by time stamping, according toembodiments as disclosed herein.

As provisioned in present specification of the 3GPP TS 36.314, latencymeasurement is done at the apparatus/eNB 100 and hence it does not caterto the UL latency measurement. The packet delay in the UL direction ismeasured/calculated as the time difference between the first time unitand the second time unit (i.e., “point in time when the PDCP SDU isprovided to upper layer entity 104 by the PDCP receiver entity 108 atthe apparatus 100” and the “point in time when PDCP SDU arrives at thePDCP Tx 206 at the UE 200”). This latency measurement takes into accountfor the HARQ retransmissions, reordering delay, the RLCretransmissions/RLC processing time and PDCP processing time as well.Further, the latency is calculated by the apparatus 100.

Referring to the FIG. 8, when the PDCP SDU (i.e., packets) arrives atthe transmit entity 206, the packets are time stamped (802) with a knownor reference value. The PDCP SDU/PDU is time stamped with the value ofSFN and sf number at which the packet is arrived from the upper layer(s)entity 204. Further, the transmit entity 206 transmits (804) the timestamped packets to the apparatus 100. Further, the Rx entity 108 (i.e.,eNB PDCP) receives the time stamped packets and provides to the upperlayer entity 104 of the apparatus 100. Before providing the packet tothe upper layer(s) entity 104, the SFN and sf number at which the packethas completed PDCP receive processing is estimated. Further, the latencyin the UL communication is calculated (806) as the time differentbetween the “SFN, sf” at which the receive PDCP processing is completedand the “SFN, sf” present in the received UL PDU. The latency can becalculated by the apparatus 100 based on the received “SFN, sf”information available in the received UL packet. Further, the apparatus100 is configured to perform (1008) corrective actions if required.

In an example, when the packets are received at the UE 200, the transmitentity 206 triggers for time stamping of the UL PDCP packet: The Timestamping of the UL PDCP PDU results in added overhead to the actualpayload. Therefore it is not always desirable to time stamp each of thePDCP UL PDU. The time stamping decision for a PDCU may depend on severalfactors and the triggers leading to decide the time stamping of the PDUas are provided below:

Every UL packet

First UL packet on the bearer/QCI

For the zeroth DL PDCP SN

Periodic time stamping of SDU/PDU based on a defined periodicity

When first UL PDCP SDU is discarded from transmission

When UL PDCP SDU discard at the apparatus 100, the PDCP Tx entity 106increases over a threshold

When the HARQ ACK is not received after a defined number ofattempts/retransmissions.

When there is an RTP/RTCP timeout

When the DL status PDU is received

When RRC/PDCP has been explicitly signaled by the network/apparatus 100to time stamp

When requested by the apparatus 100 as part of the RRC message (e.g.LatencyReportReq-r13, ulTimestampReq-r13 etc.).

Unlike the DL case, there is no need for the UE 200 to send a separatelatency report to the apparatus 100 as the time stamped PDU istransmitted in the UL using which the apparatus 100 can calculate thedelay involved. A PDCP UL PDU can be time stamped as a part of the ULdata PDU or as a new or part of UL control PDU as illustrated in FIGS.10a and 10b , FIGS. 11a and 11b and the FIG. 12 or as a part of the RRCmessage as illustrated in the FIGS. 7a -7 c.

FIG. 9 is a sequence diagram illustrating steps for determining the ULlatency by means of the UL PDU time stamping, according to embodimentsas disclosed herein.

T1 is the time at which the PDCP data arrival for the UL transmissionfrom upper layer entity 204 to the time taken for forming the PDCP PDUand transmitting to the lower layer entity 210 (i.e., lower PDCPSAP/RLC). During the time frame of T1, along with the regular PDCPtransmission PDU processing, the PDCP transmit entity 206 also timestamps (902) the UL PDU with a reference time value (e.g. SFN and sfnumber at which the packet arrived from upper layer entity 204) and thenprovided to the lower layer entity 210. Further, the RLC, the MAC andthe PHY processing is performed (904) and then the packet is transmittedover the air to the apparatus 100 during the time frame T2. The timeframe T2 also includes MAC PDU formation (multiplexing and scheduling),HARQ procedures, and other PHY processing involved in preparing the DLtransport block for transmission. The T2 also includes the over the airpropagation delay between the UE 200 transmission and the apparatus 100reception. T3 is the time frame where the apparatus 100 receives thetransmitted packet and completes (906) Physical layer (PHY), mediumaccess control (MAC) layer and RLC processing and provides the packet tothe upper layer entity/PDCP 104. T3 includes HARQ reordering procedure,HARQ retransmissions, the PHY layer processing, MAC de-multiplexing, RLCSDU formation, RLC reordering and other related L2 procedures. T4 is thetime at which the reception of the packet at the apparatus 100 PDCP/PDCPlower Service Access Point (SAP)/RLC upper SAP to the time at which thepacket is provided to PDCP upper SAP/upper layer entity 104 for postPDCP processing (908). During T4, the receiver entity/Rx PDCP entity 108at the apparatus 100 decodes the time stamped value and calculates (910)the UL latency for the received packet (e.g. SFN, sf at which the Rxentity 108 has completed processing the PDU and the time stamp valueadded to the PDU). This measured latency is the UL packet transmissionlatency and will include the cumulative delays introduced during T1, T2,T3 and T4.

In another embodiment, the method for determining the UL latency withouttime stamping PDCP PDU. In the UL, as the latency calculation is done atthe apparatus 100, it is not always necessary to time stamp on the ULpacket for estimating the latency and other alternative methods arepossible as well. If the time at which the data arrives at the UE 200transmit entity/Tx PDCP entity 206 can be estimated by the apparatus100, then it is not required to time stamp the packets. However, thelatency will be different for different bearers as the UL schedulingtakes the logical channel priority into account.

Format of the time stamped PDU and the latency report: PDCP PDU timestamping (for reference timing for DL/UL latency calculation) for thelatency calculation or the latency reporting (UE 200 assisted timeinformation to apparatus 100 for the DL latency calculation at theapparatus 100) can be done either as a new or part of an existingcontrol PDU or as a part of data PDU as detailed in conjunction with theFIGS. 10a-10b , the FIGS. 11a-11b and the FIG. 12.

The FIGS. 10a-10b illustrates different PDU formats using which the PDCPdata PDU are time stamped with reference value (e.g. the SFN and sfnumber at which the packet arrived at the PDCP from upper layer entity202). The time stamp and latency report PDU contains the followingfields:

The transmit SFN, sf [time stamped PDU] is a part of status PDU or as anew PDP control PDU or PDCP data PDU.

New bit ‘L’ (Latency) is introduced in the header which indicates thepresence of time stamping in the PDU.

The time stamp includes a 10 bit field for SFN number followed by a 4bit field for frame number.

A new PDU Type for reporting Latency may optionally be introduced asshown in table 2 below [Valid on Control PDU].

The new fields may either be inserted before the PDU SN or after the PDUSN.

Reporting of the UL Latency to the Apparatus 100:

The UL packet latency which includes T1 and T2 as illustrated in theFIG. 9 can also be reported as a part of the RRC message. It may beindicated as a response to RRC connection reconfiguration messagereceived from the apparatus 100 or as a part of the UE 200 assistanceinformation, the UE 200 information response or the like. The T1 and T2includes the PDCP queuing delay which is the time between thetransmission of the UL packet over the air interface to the apparatus100 and the time at which the packet arrived at the UE 200 to transmitPDCP entity for UL transmission. The UL latency report may contain IEswhich indicate latency in UL for different radio bearers or for a singleradio bearer as requested by the apparatus 100. If the apparatus 100requests the latency report for a specific bearer, the UE 200 reportsthe value only for the requested radio bearer. Otherwise, the UE 200reports the latency for all the activated bearers in order of activationof the same. The report will also have the UL delay which is calculatedby means of ULPDU time stamping.

log LatencyReportReq-r13

rb-Identity [Optional]

UL delay

log LatencyAvailable-r13 [TRUE]

dlLatencyRBid AbsoluteTimeInfo-r13

NumPacketsAboveThreshold-r13 bit string (max Discard Packets)

AbsoluteTimeInfo-r13 bit string (max DL delay)

The FIG. 10a illustrates the time stamped data PDU with a 12 bit PDCPSequence Number (SN). If the L bit is set to “1”, then this indicatesthat the PDCP PDU carrying the SFN and SF values after PDCP SN. Here Oct3 and Oct 4 is carrying SFN and SF values along with some reserved valueand are byte aligned. These SFN and SF value can be considered as partof PDCP header and may not be ciphered as this can help in calculatingthe latency. Alternatively another approach it can be treated as normaldata and can be ciphered as per existing procedure.

The FIG. 10b illustrates the time stamped data PDU with a 7 bit PDCP SN.If the L bit is set to 1 then immediately following bit/field carriesSFN/SF value else if this bit is set to “0”, then next immediate bit isconsidered to be data. Another way to interpret the PDCP PDU is if the Lbit is set as “0” then next 2 octets does not carry any information anddata starts from after 2 octets itself. The same format can beapplicable for 12 bit or 15 bit PDCP SN.

FIGS. 11a-11b illustrates different PDU formats using which the PDCPstatus PDU are time stamped with reference time value, according toembodiments as disclosed herein.

The FIG. 11a illustrates time stamp addition to the status PDU for PDCPwith SN of 12 bits. Such status reports may be referred as an extendedstatus report. First Missing Sequence number (FMS) field is present inthe status report in addition to the 10 bit SFN and 4 bit SF fields. Aunique PDU type field (as shown in table 2) at the beginning of thestatus report indicates if this is an extended status report carryingtime stamp/latency report in addition to the status report. These newfields may be inserted in any order prior to addition of the bitmapfields.

The FIG. 11b illustrates time stamp addition to a status PDU for PDCPwith SN of 15 bits. Such Status reports may also be referred to as anextended status report. There is no FMS field in this type of statusreport. A unique PDU type field (as shown in table 2) at the beginningof the status report indicates if this is an extended status reportcarrying time stamp/latency report in addition to the status report.These new fields may be inserted in any order prior to addition of thebitmap fields.

FIG. 12 illustrates the new PDCP control PDU introduced for the solepurpose of indicating the time stamp to the UE 200, according to anembodiment as disclosed herein. This time stamped control PDU willinclude a unique PDU type which indicates that the PDU is a time stampcontrol PDU as illustrated in the Table 2. The PDU contains a 10 bit SFNfiled, 4 bit SF field and remaining reserved bits for byte alignment. Inall these cases, the time stamped PDU may either carry only SFN and SFor it may additionally carry PDCP SN corresponding to that SFN, SF.

TABLE 2 PDCP PDU Type values Bit Description 000 PDCP status report 001Interspersed ROHC feedback packet 010 PDCP time stamp Control PDU 011PDCP extended Status Report 100 PDCP UL Packet discard report ControlPDU 101-111 reserved

Triggers and Reporting Procedure for UL Packet Loss Metrics

The UL packet loss or drop or discard can happen due to poor resourceallocation/scheduling or poor radio conditions. A packet is discarded orlost from transmission queue if there are no resource allocated for itwithin a defined time period (time period is set based on the expectedQoS). Packet discards lead to poor quality of service and can eventuallyeven lead to dropping of the MMTEL Voice/video call (due to excessiveand continuous discards). Packet loss visible at Access Stratum shall bemeasured. For DL as the data pending for transmission is available atthe apparatus 100 and the scheduling decisions are also taken by theapparatus 100, it is possible to estimate the packet discard (if any)and hence can take corrective action to minimize the same. However, inthe UL direction, the data pending for transmission is available at UE200 but the scheduling decisions are taken by the apparatus 100.Therefore, the apparatus 100 is not aware of the packet discardstatistics and hence cannot take any corrective/preventive actions tominimize it. The serving apparatus 100 need to be educated with packetdiscard statistics for the UL data, so that the apparatus 100 can makeappropriate scheduling decisions to minimize the number of discardsthereby improving the service quality.

FIG. 13 is a sequence diagram illustrating various steps involved inreporting discarded packet to the apparatus 100, according toembodiments as disclosed herein.

Due to several factors including poor resource allocation/scheduling,there are packets discarded from the transmission. A packet is discardedfrom the transmission if there is no resource allocated for the packetwithin a defined time period (time period is set based on the expectedQOS). The packet discards lead to poor quality of service and caneventually lead to dropping of the MMTEL Voice/video call (due toexcessive and continuous discards).

In the DL direction, as the data pending for the transmission isavailable at the apparatus 100 and the scheduling decisions are alsotaken by the apparatus 100, it is possible to estimate the packetdiscard (if any) and hence can take corrective action to minimize thesame. However, in the UL direction, the data pending for thetransmission is available at the UE 200 but the scheduling decisions aretaken by the apparatus 100. Therefore, the apparatus 100 is not aware ofthe packet discard statistics and hence cannot take anycorrective/preventive actions to minimize it.

In the DL, the apparatus 100 is aware of the number of packets discardedand can take the necessary corrective actions. However, in the UL theapparatus 100 is not aware of the number of packets discarded from thetransmission and hence cannot take any correction measures. Only the UE200 is aware of this statistic but cannot improve the service qualitywith this knowledge. In order to improve the service quality, theserving network/apparatus 100 has to be educated with these statistics.If the apparatus 100 is aware of the packet discard statistics, then theapparatus 100 can make appropriate scheduling decisions to minimize thenumber of discards thereby improving the service quality.

Once the trigger condition for reporting the UL packet discardstatistics to the apparatus 100 is satisfied, the UE 200 forms thepacket discard report and send it over the air interface to theapparatus 100. The apparatus 100 on receiving the report will performcorrective actions (if required) to overcome the packet discard anomaly.

At Step (1302): Logging the Number of Discarded PDU/SDU:

The UE 200 logs the number of PDCP PDU lost or discard. The discard canbe due to poor resource allocation or due to PDCP discard timer or dueto error condition like RLF, re-establishment etc. The UE 200 can alsolog information like number of PDCP PDU that have been discarded i.e.packets which are processed at PDCP by assigning PDCP SN and number ofPDCP SDU i.e. packets which are still in transmission queue and yet tobe processed.

At Step (1304): Triggers for Reporting the UL Packet Discards:

To take appropriate scheduling decisions to minimize the packet discardsin the UL, the apparatus 100 has to be made aware of the discardstatistics. The apparatus 100 or the UE 200 itself can define trigger tosend this status report to LTE apparatus 100. This can be achieved inthe following ways:

Re-establishment procedure which can occur due to handover or any othererror condition like Radio Link Failure (RLF), Random Access Channel(RACH) failure or the like.

Apparatus 100 can request the PDCP discard statistics in any of the RRCor the non-access stratum (NAS) message.

Apparatus 100 can configure the reporting of these statistics onperiodic basis, the

UE 200 can run the timer and report these after periodic timer expiry.

The UE 200 can report this if the number of discarded packets is above adefined threshold as configured by the Apparatus 100. This threshold canbe provided in any of the RRC or the NAS message and can be configuredas per the QCI or per bearer or per Logical channel group. This eventbased can be controlled through status prohibit timer so that the UE 200should not end up in sending multiple reports.

The UE 200 can report it if the Real-time Transport Protocol(RTP)/Real-Time Transport Control Protocol (RTCP) timeout has occurred.

The UE 200 can report it whenever existing MDT measurements have beenreported like during the RLF or the RACH or handover procedure.

Can be reported periodically following the first discarded packet.

At Step (1306): Method and Format to Report the UL Packet DiscardStatistics to the Apparatus 100:

The UL packet discarded may be sent either as a part of the PDCP PDUitself or as a part of the RRC message. In the former case, it caneither be sent as a new or a part of an existing UL control PDU or as apart of the UL data PDU. The report shall contain the number of packetsdiscarded during the time window under consideration (time window ispredefined or the apparatus 100 configured). Alternatively, the reportshall contain the total number of packets discarded during the PDCPsession since establishment/re-establishment of the PDCP entity. Thereport will also contain number of the PDCP PDU that have been discardedi.e. packets which are processed at the PDCP by assigning PDCP SN andthe number of PDCP SDU i.e. packets which are still in transmissionqueue and yet to be processed. The example format for PDCP control PDUis illustrated in conjunction with the FIGS. 14a and 14b . The controlPDU will have a new unique PDU type for identifying the PDCP packetdiscard statistics report control PDU as shown in Table 2.

The FIG. 14a illustrates a method where the number of UL packetsdiscarded from transmission is logged separately for the packets whichare assigned PDCP SN and for packets which are not assigned PDCP SN. The12 bit PDCP SN is considered and the fields for number of the discardedpackets are considered of the same size as that of the SN.

The FIG. 14b illustrates a method by which there is no separate fieldsto indicate to the number of packets discarded with the assigned SN orwithout the assigned SN. The 12 bit PDCP SN is considered and the fieldsfor the number of discarded packets are considered of the same size asthat of the SN.

FIGS. 15a-15c are sequence flow diagrams illustrating UL discard packetstatistics are reported as a part of the RRC message, according toembodiments as disclosed herein.

The UL discard packets report/statistics can also be reported as a partof the RRC message in one of the following ways:

If UL packet discard report is requested (1502 a) through the RRCconnection reconfiguration message, the report (1504 b) is sent to theapparatus/EUTRAN 100 through the associated RRC connectionreconfiguration complete message as illustrated in the FIG. 15 a.

As a part of the UE 200 assistance information as illustrated in theFIG. 15 b.

If configured by the apparatus 100 to provide (1502 b) the packetdiscard reports as a part of RLF recovery mechanisms/re-establishmentprocedure, the packet discard report is sent (1504 b) to apparatus 100during RRC connection re-establishment request or complete message.

If the re-establishment to the network/apparatus 100 failed, then thepacket discard report is optionally shared to the apparatus 100 over thenext RRC connection setup complete message (if configured by theapparatus 100).

If the discard report is requested (1502 c) through the UE 200information request message, the report is sent (1504 c) over the UE 200information response message as illustrated in FIG. 15 c.

The discard report may contain any one of the following contents:

Number of packets discarded per bearer.

Rate (percentage) of packets discarded over a time window per bearer.

Number or rate of packets discarded from transmission since the lastpacket discard report sent to the apparatus/eNB 100.

Separate indications for number of packets discarded with assigned PDCPSN and number of packets discarded without assigned the PDCP SN.

FIG. 16 illustrates a computing environment implementing the method forreporting latency of the packet transmission in the communicationnetwork, according to an embodiment as disclosed herein. As depicted thecomputing environment 1602 comprises at least one processing unit 1608that is equipped with a control unit 1604 and an Arithmetic Logic Unit(ALU) 1606, a memory 1610, a storage unit 1612, plurality of networkingdevices 1816 and a plurality Input output (I/O) devices 1614. Theprocessing unit 1608 is responsible for processing the instructions ofthe algorithm.

The processing unit 1608 receives commands from the control unit 1608 inorder to perform its processing. Further, any logical and arithmeticoperations involved in the execution of the instructions are computedwith the help of the ALU 1606.

The embodiments disclosed herein can be implemented through at least onesoftware program running on at least one hardware device and performingnetwork management functions to control the elements. The elements shownin FIGS. 1 through 16 include blocks which can be at least one of ahardware device, or a combination of hardware device and softwaremodule.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the embodiments herein that others can, byapplying current knowledge, readily modify and/or adapt for variousapplications such specific embodiments without departing from thegeneric concept, and, therefore, such adaptations and modificationsshould and are intended to be comprehended within the meaning and rangeof equivalents of the disclosed embodiments. It is to be understood thatthe phraseology or terminology employed herein is for the purpose ofdescription and not of limitation. Therefore, while the embodimentsherein have been described in terms of preferred embodiments, thoseskilled in the art will recognize that the embodiments herein can bepracticed with modification within the spirit and scope of theembodiments as described herein.

1. A method for reporting latency of an uplink (UL) packet transmissionin a communication network, the method comprising: receiving, by a userequipment (UE), a request message for reporting delay of a uplink (UL)packet transmission from a network entity; measuring the delay of ULpacket transmission including queuing time involved at packet dataconvergence protocol (PDCP) layer of the UE; and transmitting, by theUE, a response message including the delay of UL packet transmission tothe network entity.
 2. The method of claim 1, wherein the delay includesa delay from a UL packet arrival at PDCP upper service access point(SAP) layer of the UE until the UL packet starts to delivered to radiolink control (RLC) layer of the UE.
 3. The method of claim 2, whereinthe delay is specific to a quality of service (QoS) class identifier(QCI) on which the UL packet transmission is active.
 4. The method ofclaim 1, the request message is radio resource control (RRC) connectionreconfiguration message and the response message is RRC connectionreconfiguration complete message.
 5. The method of claim 1, the requestmessage comprises a periodicity of the response message.
 6. A method forreporting latency of an uplink (UL) packet transmission in acommunication network, the method comprising: transmitting, by a networkentity, a request message for reporting delay of a uplink (UL) packettransmission to a user equipment (UE); and receiving, by the networkentity, a response message including the delay of UL packet transmissionfrom a user equipment (UE), wherein the delay includes queuing timeinvolved at packet data convergence protocol (PDCP) layer of the UE. 7.The method of claim 6, wherein the delay includes a delay from a ULpacket arrival at PDCP upper service access point (SAP) layer of the UEuntil the UL packet starts to delivered to radio link control (RLC)layer of the UE.
 8. The method of claim 7, wherein the delay is specificto a quality of service (QoS) class identifier (QCI) on which the ULpacket transmission is active.
 9. The method of claim 6, the requestmessage is radio resource control (RRC) connection reconfigurationmessage and the response message is RRC connection reconfigurationcomplete message.
 10. The method of claim 6, the request messagecomprises a periodicity of the response message.
 11. A user equipment(UE) reporting latency of an uplink (UL) packet transmission in acommunication network, the UE comprising: a transceiver configured to:receive a request message for reporting delay of a uplink (UL) packettransmission from a network entity, measure the delay of UL packettransmission including queuing time involved at packet data convergenceprotocol (PDCP) layer of the UE, and transmit a response messageincluding the delay of UL packet transmission to the network entity; anda controller configured to control the transceiver.
 12. (canceled) 13.An apparatus for reporting latency of an uplink (UL) packet transmissionin a communication network, the apparatus comprising: a transceiverconfigured to: transmit a request message for reporting delay of auplink (UL) packet transmission to a user equipment (UE), and receive aresponse message including the delay of UL packet transmission from auser equipment (UE); and a controller configured to control thetransceiver, wherein the delay includes queuing time involved at packetdata convergence protocol (PDCP) layer of the UE.
 14. (canceled)
 15. TheUE of claim 11, wherein the delay includes a delay from a UL packetarrival at PDCP upper service access point (SAP) layer of the UE untilthe UL packet starts to delivered to radio link control (RLC) layer ofthe UE.
 16. The UE of claim 15, wherein the delay is specific to aquality of service (QoS) class identifier (QCI) on which the UL packettransmission is active.
 17. The UE of claim 11, the request message isradio resource control (RRC) connection reconfiguration message and theresponse message is RRC connection reconfiguration complete message. 18.The UE of claim 11, the request message comprises a periodicity of theresponse message.
 19. The apparatus of claim 13, wherein the delayincludes a delay from a UL packet arrival at PDCP upper service accesspoint (SAP) layer of the UE until the UL packet starts to delivered toradio link control (RLC) layer of the UE.
 20. The apparatus of claim 19,wherein the delay is specific to a quality of service (QoS) classidentifier (QCI) on which the UL packet transmission is active.
 21. Theapparatus of claim 13, the request message is radio resource control(RRC) connection reconfiguration message and the response message is RRCconnection reconfiguration complete message.
 22. The apparatus of claim13, the request message comprises a periodicity of the response message.